home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940017.txt < prev    next >
Internet Message Format  |  1994-11-13  |  15KB
  1. Date: Fri, 21 Jan 94 04:30:08 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #17
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Fri, 21 Jan 94       Volume 94 : Issue   17
  11.  
  12. Today's Topics:
  13.                        TCP-Group Digest V94 #16
  14.                 TCP MSS and TCP WIN settings (3 msgs)
  15.                  TNOS Missing Function - NOT (2 msgs)
  16.                        Wampes loopback (3 msgs)
  17.  
  18. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  19. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  20. Problems you can't solve otherwise to brian@ucsd.edu.
  21.  
  22. Archives of past issues of the TCP-Group Digest are available
  23. (by FTP only) from UCSD.Edu in directory "mailarchives".
  24.  
  25. We trust that readers are intelligent enough to realize that all text
  26. herein consists of personal comments and does not represent the official
  27. policies or positions of any party.  Your mileage may vary.  So there.
  28. ----------------------------------------------------------------------
  29.  
  30. Date: Fri, 21 Jan 94 09:50:38 GMT
  31. From: A.D.S.Benham@bnr.co.uk
  32. Subject: TCP-Group Digest V94 #16
  33. To: TCP-Group@UCSD.EDU
  34.  
  35. > ------------------------------
  36. > 
  37. > Date: Wed, 19 Jan 94 16:46:28 CST
  38. > From: Jack Snodgrass                    <kf5mg@kf5mg.ampr.org>
  39. > Subject: TCP MSS and TCP WIN settings
  40. > To: tcp-group mailling list             <tcp-group@ucsd.edu>
  41. > 
  42. > Is there any way to assign a TCP WIN and TCP MSS setting per port? 9600b ports
  43. > can use larger Window's and Packets than 1200b ports. I'm sure that it's been
  44. > asked before but now that I've got a 9600b port going, I need to know what to
  45. > do to get the most out of the system. Thanks.
  46. > 
  47. > 73's  de  Jack  -  kf5mg
  48. > Internet        -  kf5mg@kf5mg.ampr.org            -  44.28.0.14
  49. > AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home (817) 488-4386
  50. > Dialup          -  kf5mg@tcet.unt.edu              -  work (looking  for)
  51.  
  52. I put the window mod into my JNOS sources last year. I'll post the deltas next
  53. week.
  54. The settings are set with the "ifconfig <port>" subcommands. Setting the window
  55. is slightly more complicated than it might at first appear, because when one
  56. initiates a session on port <n> the reverse path traffic might arrive on port <m>.
  57. I therefore use the "tcp window" for the SYN frame, and then set the window on
  58. all other outgoing frames for that session according to the value set for the
  59. window on the port on which the replies are received.
  60.  
  61. Don't worry if it sounds too complicated, I'll mail the deltas.
  62.  
  63. 73,
  64.  
  65. Andrew Benham, G8FSL
  66. --------------------------------------------------------------------
  67. adsb@bnr.co.uk   BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
  68. adsb@bnr.ca      +44 279 402372    Fax: +44 279 402029
  69. Home:            g8fsl@g8fsl.ampr.org [44.131.19.165]
  70. --------------------------------------------------------------------
  71.  
  72. ------------------------------
  73.  
  74. Date: Wed, 19 Jan 1994 19:19:08 -0800
  75. From: Phil Karn <karn@qualcomm.com>
  76. Subject: TCP MSS and TCP WIN settings
  77. To: kf5mg@kf5mg.ampr.org
  78.  
  79. If the physical port is on the same machine as the TCP, then TCP
  80. already limits its MSS to avoid fragmentation out through that port.
  81. For example, if the other end advertises that it will accept a MSS of
  82. 1460 bytes but the MTU of the local interface you'll take to reach it
  83. is only 576 bytes, then the local TCP will use a MSS of only 536 bytes
  84. (576-40).
  85.  
  86. If the interface with the small MTU is on another router, however, the
  87. originating TCP won't know this and fragmentation will occur.
  88.  
  89. Note also that the effective window size used by TCP, the "congestion
  90. window" is always less than the window advertised by the other
  91. end. The congestion window size is controlled by the slow start and
  92. congestion control algorithms in TCP. These are not perfect, but they
  93. do help.
  94.  
  95. Phil
  96.  
  97. ------------------------------
  98.  
  99. Date: Thu, 20 Jan 94 05:53:01 CST
  100. From: Jack Snodgrass                    <kf5mg@kf5mg.ampr.org>
  101. Subject: TCP MSS and TCP WIN settings
  102. To: tcp-group@ucsd.edu
  103.  
  104. Phil Karn writes:
  105. > If the physical port is on the same machine as the TCP, then TCP
  106. > already limits its MSS to avoid fragmentation out through that port.
  107. > For example, if the other end advertises that it will accept a MSS of
  108. > 1460 bytes but the MTU of the local interface you'll take to reach it
  109. > is only 576 bytes, then the local TCP will use a MSS of only 536 bytes
  110. > (576-40).
  111.  
  112.     Well...  that's what I thought should happen, but I tried it with JNOS 
  113. 1.10x15.  There's a IFCONFIG MTU command that I used to set the MTU to a 
  114. value of 256.  The MSS was 1024 and the WINDOW was 4K.  When I made a FTP 
  115. connect, I figured that NOS would use 256 byte packets, but it used 512 
  116. byte packets.  The IFCONFIG MTU value didn't seem to have an effect.  
  117.     I took a look at the TCP*.C files. There are only a couple of places
  118. where the Tcp_mss and Tcp_window settings are assigned to a connection. It
  119. appears that it would be easy to change this to a Tcp_mss.Interface and 
  120. Tcp_window.Interface so that you could use different Window and MSS sizes 
  121. per interface. The only problem is I don't see where in the TCP*.C code 
  122. that it references what Interface it's using. Any idea how to tell what 
  123. Interface a TCP socket is going to be using?
  124.  
  125. 73's  de  Jack  -  kf5mg
  126. Internet        -  kf5mg@kf5mg.ampr.org            -  44.28.0.14
  127. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home (817) 488-4386
  128. Dialup          -  kf5mg@tcet.unt.edu              -  work (looking  for)
  129.  
  130. ------------------------------
  131.  
  132. Date: Thu, 20 Jan 1994 14:10:25 -0600
  133. From: miltonm@inetnode.austin.ibm.com (Milton Miller)
  134. Subject: TCP MSS and TCP WIN settings
  135. To: kf5mg@kf5mg.ampr.org
  136.  
  137. mss is automatically lowered to mtu-40 based on the mtu of the first
  138. hop in the routing table.  For window, you would have to rely on
  139. the congestion window I guess.
  140.  
  141. Some tcp stacks have started keeping mtu in the routing table (probably
  142. only those that use the "new" mtu probing.  Who is adding that to nos? :-)
  143.  
  144. milton
  145. --
  146. Milton Miller  KB5TKF  miltonm@austin.ibm.com
  147. I never speak for IBM
  148.  
  149. ------------------------------
  150.  
  151. Date: Thu, 20 Jan 94 09:02:13 EST
  152. From: brian@lantz.cftnet.com (Brian A. Lantz)
  153. Subject: TNOS Missing Function - NOT
  154. To: tcp-group@ucsd.edu
  155.  
  156. Come on, guys! It's a little unfair to blame TNOS for not including standard
  157. BorlandC 3.x DOS library functions in case you are running a version of the
  158. compiler that is 2-3 years old! The before mentioned function is a part of
  159. Borland's library for versions 3.0, 3.1, and 4.0.
  160.  
  161. Lack of memory.... Borland C 3.x and up uses EMS/XMS to permit virtually
  162. unlimited source size. Is this file big, yep!
  163.  
  164. As for the commment about it being perfect out of the box, NOT! If you
  165. expected that it would compile under every possible combination, your
  166. expectations are based in the clouds! Your mileage will vary!
  167.  
  168. As for TNOS support, I suggest subscribing to TNOS-TOPICS and sending the
  169. messages there. I don't know that Brian wants a lot of "how do you compile
  170. this TNOS feature" stuff in this group. We don't want to abuse his
  171. understanding.
  172.  
  173.                /----------------------------------------------/
  174.               /   Brian A. Lantz/KO4KS                       /
  175.              /                                              /
  176.             /   Packet:   KO4KS@KO4KS.#TPAFL.FL.USA.NA     /
  177.            /   Internet: brian@lantz.cftnet.com           /
  178.           /        {   printf ("Hey Jude");              /
  179.          /                bad = !make;                  /
  180.         /               better = sad_song;    }        /
  181.        /----------------------------------------------/
  182.  
  183. ------------------------------
  184.  
  185. Date: Fri, 21 Jan 94 04:26:00 -0000
  186. From: mikebw@bilow.uu.ids.net (Mike Bilow)
  187. Subject: TNOS Missing Function - NOT
  188. To: tcp-group@ucsd.edu
  189.  
  190. Cc: brian@lantz.cftnet.com
  191.  
  192. In a msg on <Jan 20 14:02>, Brian A. Lantz writes:
  193.  
  194.  BAL> Come on, guys! It's a little unfair to blame TNOS for not 
  195.  BAL> including standard BorlandC 3.x DOS library functions in 
  196.  BAL> case you are running a version of the compiler that is 2-3 
  197.  BAL> years old! The before mentioned function is a part of 
  198.  BAL> Borland's library for versions 3.0, 3.1, and 4.0.
  199.  
  200. The _dos_xxxx() form (like "_dos_getfileattr()") of the Borland library calls
  201. was added for increased source level compatibility with Microsoft library calls
  202. as of BC++ 3.0.  These are made equivalent in system header macro definitions
  203. to the old form Borland calls (like "getfileattr()").  Another motivation for
  204. the change was to more clearly indicate which functions are not part of the
  205. ANSI C specification because they are specific to the operating system or
  206. platform.  ANSI suggests that such symbols be started with the extra prepended
  207. underscore character.  Similar changes were made in designating "near" and
  208. "far" keywords as "_near" and "_far" in newer compilers.
  209.  
  210. It would be fairly easy to generate a special header file for older Borland
  211. compilers that would implement some extremely simple text translations, such as
  212. defining the newer prefaces (like "_dos_") so that they were stripped by
  213. translating them to empty text strings.  This special header file would have to
  214. be included ahead of any system header files.  Somebody has probably already
  215. done this somewhere, but I don't know of it.
  216.  
  217. Changes to the Borland assembler are a more irritating situation.  Borland
  218. doesn't really seem to care very much about the quality of TASM, essentially
  219. regarding it as a throwaway product.  Source code that assembles perfectly with
  220. TASM 2.5 (from BC++ 2.0) breaks substantially under the newer TASM 3.1 (from
  221. BC++ 3.1), a known fact for a long time.  You almost never see this with the C
  222. compilers, where source code only breaks in the opposite direction, going from
  223. newer to older compilers.  The most irritating part of it for me is that TASM
  224. actually has a switch which is supposed to allow it to emulate any prior
  225. version of TASM or MASM, but it doesn't work right.  Probably the best solution
  226. would be to provide a prebuilt ASMOBJ.LIB of the assembly modules as Phil does
  227. for the base KA9Q source kit; he originally started doing this when TC 2.0 was
  228. all that some people had and Borland didn't even make an assembler.
  229.  
  230.  BAL> Lack of memory.... Borland C 3.x and up uses EMS/XMS to permit 
  231.  BAL> virtually unlimited source size. Is this file big, yep!
  232.  
  233. BC++ 2.0 comes with two different command-line versions, BCC.EXE and BCCX.EXE. 
  234. BCC runs in real mode, while BCCX runs in protected mode with an included DOS
  235. extender.  You can also use compiler switches on BCC to enable it to use
  236. XMS/EMS while compiling.
  237.  
  238. There are some bugs in the old Borland tools that can cause serious XMS/EMS
  239. corruption, and this can be devastating if you are running SMARTDRV or a
  240. similar disk cache which maintains disk buffers in XMS/EMS.  BCCX spawns the
  241. real mode linker, TLINK, instead of the protected mode linker, TLINKX.  If you
  242. use the "-l" switch on BCCX to pass an argument to the linker which enables the
  243. use of XMS/EMS, then this will conflict with the loaded DOS extender and very
  244. bad things will occur.  When using BCCX, you must either live with the real
  245. mode linker and no XMS/EMS, or use the protected mode linker manually by
  246. starting TLINKX from the command line.  By default, NOS MAKEFILEs invoke the
  247. compiler as a final step just to run the linker, and this might have to be
  248. changed.  The real mode linker should work fine for NOS in most cases, since
  249. you will probably run out of DGROUP space long before you run out of symbol
  250. space.
  251.  
  252. As was noted by someone else, the MAKE utility can be invoked with the "-S"
  253. switch to enable swapping itself out of memory, but there is a fairly serious
  254. speed penalty for that.  When I was compiling NOS on a 386SX-16 in the old
  255. days, it took about an hour from scratch.  On my current system, running the
  256. compiler in an OS/2 DOS emulation with DPMI seeing a lot of virtual memory, it
  257. takes about three or four minutes.
  258.  
  259.  BAL> As for TNOS support, I suggest subscribing to TNOS-TOPICS and 
  260.  BAL> sending the messages there. I don't know that Brian wants a 
  261.  BAL> lot of "how do you compile this TNOS feature" stuff in this 
  262.  BAL> group. We don't want to abuse his understanding.
  263.  
  264. Why are you referring to yourself in the third person?  Have you been reading
  265. "The Education of Henry Adams" or something?
  266.  
  267. -- Mike
  268.  
  269. ------------------------------
  270.  
  271. Date: Thu, 20 Jan 94 15:55:30 EDT
  272. From: "Jan Jaeger" <JANJ@ACCIVM.acci.COM.AU>
  273. Subject: Wampes loopback
  274. To: tcp-group@ucsd.edu
  275.  
  276. I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3).
  277. I seem to have run into a problem where packets send over the loopback
  278. interface cause wampes to crash.  The problem is that loopback->send
  279. is defined as NULLFP in iface.c and ip_route() tries to call (loopback->send).
  280. I have also compiled wampes in an RS6K (3.2.4) and the same problem exist.
  281. Am I safe to assume that this is not a porting problem? (It still needs to
  282. be fixed of course).
  283.  
  284. Jan PA3EFU/VK3CEX
  285.  
  286. ------------------------------
  287.  
  288. Date: Thu, 20 Jan 94 21:40:00 MST
  289. From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
  290. Subject: Wampes loopback
  291. To: JANJ@ACCIVM.acci.COM.AU, tcp-group@ucsd.edu
  292.  
  293. > I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3).
  294.  
  295. Could  you  send  me  your  changes,  so  I  can  merge  them  into  the
  296. distribution?
  297.  
  298. > I seem to have run into a problem where packets send over the loopback
  299. > interface cause wampes to crash.  The problem is that loopback->send
  300. > is defined as NULLFP in iface.c and ip_route() tries to call (loopback->send).
  301. > I have also compiled wampes in an RS6K (3.2.4) and the same problem exist.
  302. > Am I safe to assume that this is not a porting problem? (It still needs to
  303. > be fixed of course).
  304.  
  305. This can only  happen  if you set up a route to some  address  different
  306. from 127.0.0.1 thru the loopback interface.  Just don't do this.  In the
  307. next  version of WAMPES I will put in a  safeguard,  which  will  ignore
  308. packets routed this way, instead of crashing the system.
  309.  
  310. > Jan PA3EFU/VK3CEX
  311.  
  312. --
  313. Dieter Deyke - deyke@fc.hp.com - dk5sg@db0sao.ampr.org
  314.  
  315. ------------------------------
  316.  
  317. Date: Fri, 21 Jan 94 05:01:00 -0000
  318. From: mikebw@bilow.uu.ids.net (Mike Bilow)
  319. Subject: Wampes loopback
  320. To: tcp-group@ucsd.edu
  321.  
  322. Cc: JANJ@ACCIVM.acci.COM.AU
  323.  
  324. In a msg on <Jan 20 19:55>, Jan Jaeger of writes:
  325.  
  326.  JJ> I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3).
  327.  
  328. Great!  We have one of those dinosaurs here.  Unfortunately, it is running AIX.
  329.  Still worse, it is running AIX v2, since AIX v3 needs the RS machines and will
  330. not run on the RT machines.  I think we have the native TCP/IP support, but no
  331. one knows where the manual is, and no one at IBM seemed to care much about
  332. locating another one even when we dangled small bills in front of them.
  333.  
  334. Is your port available at any FTP site, ideally UCSD.EDU?
  335.  
  336. -- Mike
  337.  
  338. ------------------------------
  339.  
  340. End of TCP-Group Digest V94 #17
  341. ******************************
  342.